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REMARKS 

Applicant appreciates the time taken by the Examiner to review Applicant's present 
application. This application has been carefully reviewed in light of the Official Action mailed 
January 5, 2005. Applicant respectfully requests reconsideration and favorable action in this 
case. 

Specification Objections 
The specification stands objected to as failing to comply with 37 C.F.R. § 1.56. 
Applicant has updated the serial number of the Provisional Patent Application to which the 
present application claims benefit. Accordingly, withdrawal of this objection is respectfully 
requested. 

Claim Objections 

The numbering of the Claims is not in accordance with 37 C.F.R. § 1 .126. There is no 
Claim 1 1 present in the originally filed papers. Applicant has corrected the numbering of the 
claims (i.e. Claims 12-17 are now 11-26, reference to Claim 12 in the originally filed patent 
application is now reference to Claim 11, etc.). 

The Examiner pointed out that Claim 20 "generic Objection" in Claim 20 should read 
"generic objects". Applicant has amended claim 20 accordingly. Therefore, withdrawal of this 
objection is respectfully requested. 

Drawing Objections 

Applicant submits three sheets of Replacement Drawings to replace the six sheets of 
drawings in the original application. These Replacement Drawings are intended to increase the 
quality of the drawings. FIGURES 1, 2 and 3 have been combined into Replacement Sheet 1, 
FIGURES 3 and 5 into Replacement Sheet 2 and FIGURES 6 has been placed on 
Replacement Sheet 3. We submit that these Replacement Drawings do not add to or amend 
the FIGURES but merely clarify the FIGURES. 



Rejections under 35 U.S.C. S 112 
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Claims 5, 13 and 23 stand rejected under 35 U.S.C. § 1 12, second paragraph. 
Applicant respectfully traverses this rejection. Claim 5 recites, for example, that "set of generic 
objects is based upon an industry standard for workflow management." Thus, the generic 
objects can be defined based on a reference model provided by an industry standard setting 
body, in the workflow area, for example, the Workflow Management Coalition promulgates 
standards for workflow management. Those of skill in the art would be familiar with these 
standards and, based on the application as filed, understand how to construct a set of generic 
objects based on the reference models provided by the Workflow Management Coalition. See, 
U 0037. As one of skill in the art would be familiar with Workflow Management Coalition, he or 
she would be able to construct a generic object model based on reference models provided by 
that body. However, it should be noted that present invention is not limited to standards set by 
the Workflow Management Coalition, but can incorporate new industry standards as they 
promulgated by other groups. Applicant therefore believes that Claims 5, 13 and 23 are 
sufficiently definite and request withdrawal of the rejection. 

Rejections under 35 U.S.C. S 103 

Claims 1-2, 5-7, 91-10, 13-15, 17-20 and 23-25 stand rejected as obvious over U.S. 
Publication No. 20030023662 ("Yaung") in view of U.S. Publication No. 20030005406 ("Lin"). 

Claim 1 as amended recites a public API for a set of heterogeneous workflow engines 
and "a plurality of adapters, each adapter configured to interface with a workflow engine API, 
wherein each workflow engine API is associated with an underlying workflow engine from a set 
of heterogeneous workflow engines . . . wherein each adapter is operable to map said set of 
generic objects to a set of native objects for a corresponding underlying workflow engine." 
Thus, in Claim 1 , the adapters map the generic objects of the public API to APIs of at least two 
different types of workflow engines (i.e., heterogeneous workflow engines). Consequently, the 
same public API can be deployed for multiple types of workflow engines. In this manner, the 
same application can utilize the same public API to access multiple workflow engines that may 
themselves have different APIs. 

The Examiner cites Yaung as teaching translating methods for server side object native 
code used by a workflow and Lin as teaching a workflow/data store API mapping that provides 
access to vendor specific data store APIs through a work flow. Applicant submits that the 
portions of Yaung and Lin cited by the Examiner, alone or in combination, however, do not 
teach a public workflow engine API that allows a single application to interface with multiple 
workflow engines. 
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Instead, Yaung teaches a system that allows clients to utilize a particular workflow 
engine and other services. In this case, it is the services rather than the workflow engines that 
are heterogeneous. Furthermore, the heterogeneous services are not provided with a public 
API. More particularly, the architecture of Yaung provides an abstract service class, a 
WorkFlowService class and another service class type. The general service class type 
provides methods and objects that all services, including workflow services, must implement to 
make their services available to users. The abstract WorkFlowService class provides methods 
and objects that all workflows must implement and the other service class type includes 
methods and objects that all services that particular service type of service must implement 
(e.g., services that all search engines must implement). The WorkFlowService server side 
class 506 and the WorkFlowService client side class 508 provide the methods and objects for 
one vendor implementation of a work flow service . The WorkFlowSerivice service side class 
506 and WorkFlowService client side class 508 inherit objects and methods from the 
WorkFlowService class (as these objects and methods are used by all workflow services) and 
the generic service object (as these objects and methods are used by all services). 

In FIGURE 7, each client 550 includes a workflow service object 552 instantiated from 
the WorkFlowService client side class (i.e., the vendor specific class). The workflow server 556 
includes a workflow service object (server) side 558 that maintains information on a particular 
vendor implementation of a workflow engine . Methods invoked in on the client side based on 
the vendor specific WorkFlowService client side object 552 are transferred to the workflow 
server. The workflow server object (again workflow engine implementation specific) then 
translates the methods into the native code used by the workflow engine. See, Yaung 1ffl122- 
128. 

Thus, in Yaung, methods invoked by clients are workflow engine specific. The workflow 
server appears to translate these workflow engine specific methods into that native language 
used by the workflow engine. There does not, however, appear to be a public API that clients 
can use that has associated adapters to translate generic objects to any number of different 
workflow engine specific native objects. Put another way, it appears that methods generated by 
clients of Yaung are workflow engine implementation specific as they are based on the 
implementation specific workflow client object. The workflow engine implementation specific 
server side object then translates the methods for use by the underlying workflow engine of the 
particular implementation. To the extent the server side object can be considered an API, for 
the sake of argument, it is vendor implementation specific API. There is no teaching or 
suggestion, however, of a public API for heterogeneous workflow engines (i.e., workflow 
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engines having different implementations) that has associated adapters to translate generic 
objects of the public API to native objects of heterogeneous workflow engines because the 
server side workflow objects of Yaung are vendor implementation specific. 

Lin discusses the use of workflow engine APIs to access objects in different data stores. 
However, in Lin, there still appears to be a single workflow engine with which the APIs are 
associated. Thus, the multiple data store APIs appear to map to APIs for a single workflow 
engine. While these APIs may allow clients to access objects from data stores, there is no 
public API for heterogeneous workflow engines with associated adapters that allows generic 
objects to be translated to native objects of multiple heterogeneous workflow engines. 
Moreover, there is no teaching or suggestion in Lin that the workflow APIs or data store APIs 
should utilize a generic object model as there is no indication in the portions cited by the 
Examiner as to how the mapping between workflow APIs and data store APIs is achieved. 

Thus, neither Yaung nor Lin, alone or combination, teach a public API for 
heterogeneous workflow engines and "a plurality of adapters, each adapter configured to 
interface with a workflow engine API, wherein each workflow engine API is associated with an 
underlying workflow engine from a set of heterogeneous workflow engines . . . [and] wherein 
each adapter is operable to map said set of generic objects to a set of native objects for a 
corresponding underlying workflow engine." Accordingly, Applicant respectfully requests 
allowance of Claim 1 and the respective dependent claims. 

Claim 9 recites "a public API comprising a set of generic objects for the heterogeneous 
workflow engines, a first adapter configured to map said set of generic objects to said first set of 
native objects [for a first workflow engine] and a second adapter configured to map said set of 
generic object to said second set of native objects [for the second workflow engine]." Claim 9 
further recites that the first and second workflow engines are heterogeneous. Thus, as with 
Claim 1 , Claim 9 includes a public API for heterogeneous workflow engines and associated 
adapters to map generic objects of the public API to native objects used by the heterogeneous 
workflow engines. For similar reasons as discussed in conjunction with Claim, Applicants 
believe that Yaung and Lin, alone or in combination, do not teach or suggest Claim 9. 
Therefore, Applicant respectfully requests allowance of Claim 9 and the respective dependent 
claims. 

Claim 17, as amended, recites "creating a public API for at least two heterogeneous 
workflow engines comprising a set of generic objects . . . and mapping said set of generic 
objects to a set of native objects for each of said underlying workflow engine engines." Again, 
the generic objects of a public API for heterogeneous workflow engines is mapped to the native 
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objects of the heterogeneous workflow engines. As discussed above, however, Yuang and Lin 
do not teach the use of an API with generic objects that are mapped to native objects for 
heterogeneous workflow engines. To the extent the server side object of Yuang can be 
considered an API, the server side object is specific to a particular vendor implementation of a 
workflow engine and is not used to process methods for multiple heterogeneous workflow 
engines. Lin further teaches mapping of data store APIs to the workflow engine API of a single 
workflow engine. For these reasons, Applicant respectfully requests allowance of Claim 17 and 
the respective dependent claims. 

Applicant has now made an earnest attempt to place this case in condition for 
allowance. Other than as explicitly set forth above, this reply does not include an acquiescence 
to statements, assertions, assumptions, conclusions, or any combination thereof in the Office 
Action. For the foregoing reasons and for other reasons clearly apparent, Applicant respectfully 
requests full allowance of the pending Claims. The Examiner is invited to telephone the 
undersigned at the number listed below for prompt action in the event any issues remain. 

An extension of one (1) month is requested and a Notification of Extension of Time 
Under 37 C.F.R. § 1.136 with the appropriate fee is enclosed herewith. 

The Director of the U.S. Patent and Trademark Office is hereby authorized to charge 
any fees or credit any overpayments to Deposit Account No. 50-3183 of Sprinkle IP Law Group. 



Date: May 05, 2005 

1301 W. 25 th Street, Suite 408 
Austin, TX 78705 
Tel. (512)637-9220 

Fax. (512) 371-9088 



Respectfully submitted, 




Sprinkle IP Law Group 

Attorneys for Applicant 



John L. Adair 
Reg. No. 48,828 
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IN THE DRAWINGS : 

Please cancel the drawing sheets in the present Application and add the corresponding 
.attached Replacement Sheets. 



